The Challenge of Productivity Measurement

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "The Challenge of Productivity Measurement"

Transcription

1 Proceedings: Pacific Northwest Software Quality Conference, 2006 The Challenge of Productivity Measurement David N. Card Q-Labs, Inc Biography- David N. Card is a fellow of Q-Labs, a subsidiary of Det Norske Veritas. Previous employers include the Software Productivity Consortium, Computer Sciences Corporation, Lockheed Martin, and Litton Bionetics. He spent one year as a Resident Affiliate at the Software Engineering Institute and seven years as a member of the NASA Software Engineering Laboratory research team. Mr. Card is the author of Measuring Software Design Quality (Prentice Hall, 1990), co-author of Practical Software Measurement (Addison Wesley, 2002), and co-editor ISO/IEC Standard 15939: Software Measurement Process (International Organization for Standardization, 2002). Mr. Card also serves as Editor-in-Chief of the Journal of Systems and Software. He is a Senior Member of the American Society for Quality. Abstract - In an era of tight budgets and increased outsourcing, getting a good measure of an organization s productivity is a persistent management concern. Unfortunately, experience shows that no single productivity measure applies in all situations for all purposes. Instead, organizations must craft productivity measures appropriate to their processes and information needs. This article discusses the key considerations for defining an effective productivity measure. It also explores the relationship between quality and productivity. It does not advocate any specific productivity measure as a general solution. Introduction A productivity measure commonly is understood as a ratio of outputs produced to resources consumed. However, the observer has many different choices with respect to the scope and nature of both the outputs and resources considered. For example, outputs might be measured in terms of delivered product or functionality, while resources might be measured in terms of effort or monetary cost. Productivity numbers may be used in many different ways, e.g., for project estimation and process evaluation. An effective productivity measure enables the establishment of a baseline against which performance improvement can be measured. It helps an organization make better decisions about investments in processes, methods, tools, and outsourcing. In addition to the wide range of possible inputs and outputs to be measured, the interpretation of the resulting productivity measures may be affected by other factors such as requirements changes and quality at delivery. Much of the debate about productivity measurement has focused narrowly on a simplistic choice between function points and lines of code as size measures, ignoring other options as well as many other equally important factors. Despite the complexity of the software engineering environment, some people believe that a single productivity measure can be defined that will work in all circumstances and satisfy all measurement users needs. This article suggests that productivity must be viewed and measured from multiple perspectives in order to gain a true understanding of it. International Standards One might hope to look to the international standards community for guidance on a common industry problem such as productivity measurement. While some help is available from this direction, it is limited. The most relevant resources are as follows: IEEE Standard 1045, Software Productivity Measurement [2] describes the calculation of productivity in terms of effort combined with counts of lines of code or function points. It recommends variations to address software re-use and maintenance scenarios. It provides a project characterization form, but does not discuss how different characteristics might lead to different productivity measures. 1

2 ISO/IEC Standard 15939, Software Measurement Process [1]. This standard is the basis for the Measurement and Analysis Process Area of the Capability Maturity Model Integration [4]. ISO/IEC Standard contains two key elements: a process model and an information model. The process model identifies the principal activities required for planning and performing measurement. The ISO/IEC information model defines three levels of measures: indicators, base measures, and derived measures. Figure 1 illustrates these different levels of measurement. The counts of inputs and outputs used to compute productivity are base measures in this terminology. Each base measure quantifies a single measurable attribute of an entity (process, product, resource, etc.) Multiple values of base measures are combined mathematically to form derived measures. A base or derived measure with an associated analysis model and decision criteria forms an indicator. SEI technical reports discuss how to define effort [12] and size measures [13], but give little guidance on how they can be combined to compute things such as productivity. Thus, the SEI reports discuss considerations in defining base measures (using the ISO/IEC Standard terminology), while IEEE Standard 1045 suggests methods of combining base measures to form derived measures of productivity. Note that none of these standards systematically addresses the factors that should be considered in choosing appropriate base measures and constructing indicators of productivity for specific purposes. That is the topic of the rest of this article. Information Product Combination of Indicators and Interpretations Level of Analysis and Flexibility Indicator Base or Derived Measure With Decision Criteria Derived Measure Function of Two or More Base Measures Level of Data Collection and Standardization Base Measure Quantification of a Single Attribute Attribute Characteristic of a Process or Product Figure 1. Levels of a Measurement Construct The Concept of Productivity Many different approaches to measuring productivity have been adopted by industry for different purposes. This section discusses the common approaches and makes recommendations for their application. The basic equation for productivity is as follows: 2

3 productivity = output _ produced resources _ consumed The simple model of Figure 2 illustrates the principal entities related to the measurement and estimation of productivity. A process converts input into output consuming resources to do so. We can focus on the overall software process or a subprocess (contiguous part of the process) in defining the scope of our concern. The input may be the requirements statement for the overall software process and for the requirements verification subprocess, or the detailed design for the coding process (as another example). Thus (requirements) input may consist of initial product requirements or previous work products provided as input to a subprocess. In this model the requirements are relative to the process or subprocess under consideration. The (product) output may be software or another work product (e.g., documentation). Resources typically have a cost (in the local currency) associated with them. Usually, effort is the primary resource of concern for software development. The output has a value associated with it (typically the price to the customer). The value is a function of capability, timeliness, quality, and price. Cost Resources (Effort) Value Requirements (Input) Process or Subprocess Product (Software) Figure 2. Simple Model of Productivity Using this model, the numerator of productivity may be the amount of product, volume of requirements, or value of the product (that is, things that flow into the process or subprocess). The denominator of productivity may be the amount or cost of the resources expended. The designer of a productivity measure must define each of the elements of the model in a way that suits the intended use and environment in which the measurement is made. The product of software development is complex. In addition to code, other artifacts such as data, documentation, and training may be produced. If the resources expended in the production of each artifact can be distinguished, then separate productivity numbers may be computed for each. However, the most common approach is to use a broad size measure (such as lines of code or function points) with a consolidated measure of resources. Figure 2 is a generic model. The designer of a productivity measure must address the following issues in defining a precise productivity indicator: Scope of outputs (product) which products get counted? Scope of resources which resources get counted? Requirements (or other input) churn what if the target changes during development? Quality at delivery how are differences in quality accounted for? 3

4 These issues are discussed in the following sections. Size Measurement This section describes the two most common methods for measuring size the numerator of the productivity equation. These are Function Points and Lines of Code. Function Points is a functional (input) size measure, while Lines of Code is a physical (output) size measure. The amount of functionality (requirements or input) satisfied usually corresponds to the amount of product delivered. However, the value of a product from the customer perspective often does not track closely to its size. Reuse and code generation tools affect the effort to produce a given quantity software. That is more requirements can be satisfied and more output produced with less effort. Consequently the effects of these technologies must be considered in determining productivity either by weighting the size measures or defining multiple productivity measures for different development scenarios. More than one size measure may be needed to capture all of the information needed about the quantity of product delivered. That is software produced by different methods may need to be counted separately. Software size, itself, has an effect on productivity. The phenomenon of Diseconomy of Scale has long been recognized in software development [9]. This means that the productivity of larger software projects is lower than the productivity of smaller projects, all other factors being equal. Thus, comparisons of projects of different sizes must take this effect into account. This effect is non-linear so that as the range of software sizes increases, the differences in productivity become larger. Function Points The Function Point Analysis (FPA) approach has been widely accepted for estimating human-computer interface, transaction processing, and management information systems. FPA involves a detailed examination of the project s interface description documents and/or prototypes of user interfaces. Usually, these are developed early in the project s life cycle. When they are not available, similar materials from previous projects may be analyzed to obtain analogous data. The FPA approach rates the complexities of interface elements in a systematic way. Nevertheless, this approach still exhibits a significant element of subjectivity. Many different FPA counting algorithms have been developed. The following discussion is based on the Function Point Counting Practices Manual [7]. Different, but similar, measures are required for each of five types of interface elements that are counted. The complexity of each interface element is quantified by considering the presence of three specific attributes. Separate counting rules are applied to each interface type. FPA was originally developed and promoted as an estimation technique. Because it is based on information that is available relatively early in the life cycle, it can be quantified with greater confidence than physical size measures (such as Lines of Code) during project planning. However, one of the disadvantages of FPA is that even after the project is complete, the measurements of Functions Points still remain subjective. Key contributors to the accuracy of this estimation approacht are the skill of the measurement analyst conducting the function point count, as well as the completeness and accuracy of the descriptive materials on which the count is based. Lines of Code Perhaps, the most widely used measure of software size is Lines of Code. One of the major weaknesses of Lines of Code is that it can only be determined with confidence at project completion. That makes it a good choice for measuring productivity after the fact, however. The first decision that must be made in measuring Lines of Code is determining what to count. Two major decisions are 1) whether to count commentary or not, and 2) whether to count lines or statements. From the productivity perspective, comments require relatively little effort and add no functionality to the product so they are commonly excluded from consideration. 4

5 The choice between lines and statements is not so clear. Line refers to a line of print on a source listing. A statement is a logical command interpretable by a compiler or interpreter. Some languages allow multiple logical statements to be placed on one line. Some languages tend to result in long statements that span multiple lines. These variations can be amplified by coding practices. The most robust measure of Lines of Code is generally agreed to be non-comment source statements. A major factor in understanding productivity, especially in product line development, is taking into account the sources of the software that go into a delivery. Usually, at least three categories are used: New software that is developed specifically for this delivery Modified software that is based on existing software, but that has been modified for this delivery Reused pre-existing software that is incorporated into the delivery without change The resources required to deliver these classes of software are different. Modified software takes advantage of the existing design, but still requires coding, peer review, and testing. Reused software usually does not require design, coding, or peer review, but does require testing with the other software. These differences can be taken into consideration by weighting the Lines of Code of each type or by computing separate productivity numbers for each type. The latter approach requires recording resource (effort) data separately for each type of software, so it tends to be less popular. The result of the weighting approach often is described as Equivalent Source Lines of Code. Typical values for weighting schemes are as follows: New 100% Modified 40 to 60% Reused 20 to 40% Ideally the weights are determined by the analysis of historical data from the organization. The concept of Equivalent Source Lines of Code makes it possible to determine the productivity of projects with varying mixes of software sources. Alternatively, some general adjustment factor can be applied to the software size as a whole to account for reuse and other development strategies. However, that captures the effect less precisely than counting the lines from different sources separately. Other Size Measures Many additional size measures have been proposed, especially to address object-oriented development. These include counts of use cases, classes, etc. Card and Scalzo [11] provide a summary of many of them. However, none are widely accepted in practice. That doesn t mean that they should not be considered. However, their use in productivity measures does not eliminate concern for the factors discussed here. Resource Measurement The denominator, resources, is widely recognized and relatively easily determined. Nevertheless, the obvious interpretation of resources (whether effort or monetary units) can be misleading. The calculation of productivity often is performed using only the development costs of software. However, the magnitude of development resources is somewhat arbitrary. The two principal considerations that must be addressed are 1) the categories of cost and effort to include and 2) the period of the project life cycle over which they are counted. Four categories of labor may be considered in calculating productivity: engineering, testing, management, and support (e.g., controller, quality assurance, and configuration management). Limiting the number of categories of labor included increases the apparent productivity of a project. Calculations of productivity in monetary units may include the costs of labor as well as facilities, licenses, travel, etc. When comparing 5

6 productivity across organizations it is essential to ensure that resources are measured consistently, or that appropriate adjustments are made. Requirements Churn and Quality at Delivery Figures 3a, 3b, and 3c illustrate the effect of the period of measurement on the magnitude of the resource measure. These figures show the resource profile (effort or cost) for a hypothetical project broken into three categories: production, rework, and requirements breakage. Requirements breakage represents work lost due to requirements changes. This may be 10 to 20 percent of the project cost. Rework represents the resources expended by the project in repairing mistakes made by the staff. Rework has been shown to account for 30 to 50 percent of the costs of a typical software project [5]. Usually, rework effort expended prior to delivery of the product is included in the calculation of productivity, while rework after delivery usually is considered maintenance. However, this latter rework is necessary to satisfy the customer. A comparison of Figures 3a and 3b shows the effect of delivery date on productivity. The overall resources required for the two projects to deliver a product that eventually satisfies the customer is assumed to be identical. However, the project in Figure 3a delivers earlier than the project in Figure 3b. Consequently the development effort of the project in Figure 3a seems to be smaller, resulting in apparently higher productivity. However, this project will require more rework during maintenance than the project in Figure 3b. The project in Figure 3b is similar in every other respect except that it delivered later and had more time to fix the identified problems. This latter project would be judged to have lower development productivity, although the total life cycle costs of ownership would be very similar for the two projects. Thus, development cost (and consequently apparent productivity) are affected by the decision on when and under what conditions the software is to be delivered. The true productivity of the two projects is essentially identical. Comparing Figures 3b and 3c show the impact of requirements churn. While the two projects deliver at the same time, and so exhibit the same apparent productivity, they may experience different amounts of requirements breakage. The project in Figure 3b, with the larger requirements breakage actually has to produce with a higher real productivity to deliver the same output as the project in Figure 3c where requirements breakage is lower. Delivery Development Maintenance Effort Production Rework Requirements Breakage Time Figure 3a Apparent High Productivity Project 6

7 Delivery Development Maintenance Effort Production Rework Requirements Breakage Time Figure 3b Apparent Low Productivity Project Delivery Development Maintenance Effort Production Rework Requirements Breakage Time Figure 3c Highest Effective Effort (Lowest Productivity) In summary, when determining what value to put in the denominator of the productivity equation, the resources required for rework after delivery should be added to the development cost, while the resources associated with requirements breakage should be subtracted. Obviously, tracking the data necessary to do this is difficult, but such data helps to develop a more precise understanding of productivity. Typical Productivity Calculations Measures of size and resources may be combined in many different ways. The three common approaches to defining productivity based on the model of Figure 2 are referred to as physical, functional, and economic productivity. Regardless of the approach selected, adjustments may be needed for the factors of diseconomy of scale, reuse, requirements churn, and quality at delivery. Physical Productivity This is a ratio of the amount of product to the resources consumed (usually effort). Product may be measured in lines of code, classes, screens, or any other unit of product. Typically, effort is measured in terms of staff hours, days, or months. The physical size also may be used to estimate software performance factors (e.g., memory utilization as a function of lines of code). Functional Productivity 7

8 This is a ratio of the amount of the functionality delivered to the resources consumed (usually effort). Functionality may be measured in terms of use cases, requirements, features, or function points (as appropriate to the nature of the software and the development method). Typically, effort is measured in terms of staff hours, days, or months. Traditional measures of Function Points work best with information processing systems. The effort involved in embedded and scientific software is likely to be underestimated with these measures, although several variations of Function Points have been developed that attempt to deal with this issue [14]. Economic Productivity This is a ratio of the value of the product produced to the cost of the resources used to produce it. Economic productivity helps to evaluate the economic efficiency of an organization. Economic productivity usually is not used to predict project cost because the outcome can be affected by many factors outside the control of the project, such as sales volume, inflation, interest rates, and substitutions in resources or materials, as well as all the other factors that affect physical and functional measures of productivity. However, understanding economic productivity is essential to making good decisions about outsourcing and subcontracting. The basic calculation of economic productivity is as follows: Economic Productivity = Value/Cost Cost is relatively easy to determine. The numerator of the equation, value, usually is recognized as a combination of price and functionality. More functionality means a higher price. Isolating the economic contribution of the software component of a system can be difficult. Often, that can be accomplished by comparison with the price of similar software available commercially. Ideally, the revenue stream resulting from a software product represents its value to the customer. That is, the amount that the customer is willing to pay represents its value. Unfortunately, the amount of revenue can only be known when the product has finished its useful life. Thus, the value must be estimated in order to compute economic productivity, taking into consideration all the factors affecting the customer s decision to buy. Thus, Value = f(price, Time, Quality, Functionality) Poor quality may result in warranty and liability costs that neutralize revenue. Similarly, time must be considered when determining the economic value of a product - a product which is delivered late to a market will miss sales opportunities. Thus, the amount of revenue returned by it will be adversely affected. Consequently, the calculation of value for economic productivity must include timeliness and quality, as well as price and functionality. Note that this definition of economic productivity does not take into consideration the cost to the developer of producing the product. Whether or not a product can be produced for a cost less than its value (expected sales), is another important, but different, topic. Comparing Productivity Numbers Having chosen a productivity calculation along with appropriate definitions of resource and size measures, productivity numbers can be produced. Comparing productivity numbers from a series of closely related projects (e.g., members of a product line) is straightforward. However, making comparisons across different projects or organizations requires greater care. Many factors affect the productivity achieved by a project. Most estimation models provide adjustment factors to account for many of these factors. Generally, these influencing factors fall into two categories: controllable and inherent. These two categories of factors must be handled differently when comparing productivity across projects or organizations. 8

9 Controllable factors can be changed by management. They are the result of choice, although not always desirable choices. Examples of controllable factors include personnel experience, development environment, and development methods. Depending on the purpose of the productivity comparison adjustments may be made to account for these factors, especially when using productivity to estimate project effort. However, productivity comparisons of completed projects often are made specifically to evaluate the choices made by an organization, so usually no adjustments are made for the controllable factors when comparing productivity results from different projects Inherent factors are those that are built into the problem that the software developers are trying to solve. Examples of inherent factors (beyond the control of the software development team) include: Amount of software developed (diseconomy of scale) Application domain (e.g., embedded versus information systems) Customer-driven requirements changes The software development team cannot choose to develop less software than necessary to do the job, build a different application than the customer ordered, or ignore customer change requests in the pursuit of higher productivity. Consequently, adjustments must be made for the inherent factors when comparing productivity results from different projects. While quality at delivery is a controllable factor, the eventual quality required by the customer is not, so adjustments also should be made for post delivery repair, too. Summary Measures of product size and resources must be carefully selected in deciding upon the construction of a productivity indicator. It is not simply a choice between Function Points, Lines of Code, or another size measure. Many other factors also must be considered. Table 1 summarizes the reported impact of some of the factors previously discussed, as a percent of the project s effort. Table 1. Factors in Productivity Measurement Factor Typical Impact (%) References Requirements Changes 10 to 40 8, 9, 10 Diseconomy of Scale 10 to 20 8 Post Delivery Repair 20 to 40 5, 9 Software Reuse 20 to 60 8, 9 Left unaccounted for, the variable effects of these factors on measured productivity can overwhelm any real differences in project performance. Even if an organization finds itself unable to measure all of these factors, they should be excluded consciously, rather than simply ignored. No single measure of productivity is likely to be able to serve all the different needs of a complex software organization, including project estimation, tracking process performance improvement, benchmarking, and demonstrating value to the customer. Multiple measures of productivity may be needed. Each of these must be carefully designed. This article attempted to identify and discuss some of the most important issues that must be considered. In particular, it did not attempt to define a universal measure of productivity. References [1] ISO/IEC Standard 15939: Software Measurement Process, International Organization for Standardization, [2] IEEE Standard for Software Productivity Metrics, IEEE Std , IEEE Standards Board, 1993 [3] J. McGarry, D. Card, et al., Practical Software Measurement, Addison Wesley,

10 [4] M. Crissis, M. Konrad and C. Schrum, Capability Maturity Model Integration, Addison Wesley, 2003 [5] R. Dion, Process Improvement and the Corporate Balance Sheet, IEEE Software, September 1994 [6] D. Wheeler and D. Chambers, Understanding Statistical Process Control, SPC Press, 1992 [7] Function Points Counting Practices, Manual Version 4.0, International Function Point Users Group, 1998 [8] B. Boehm, Software Engineering Economics, Prentice Hall, 1981 [9] M. J. Bassman, F. McGarry, and R. Pajerski, Software Measurement Guidebook, NASA Software Engineering Laboratory, 1994 [10] R.B. Grady, Practical Software Metrics for Project Management and Process Improvement, Prentice Hall, 1992 [11] D. N. Card and B. Scalzo, Estimating and Tracking Object-Oriented Software Development, Software Productivity Consortium, 1999 [12] Wolfhart Goethert, Elizabeth Bailey, & Mary Busby, Software Effort & Schedule Measurement: A Framework for Counting Staff-Hours and Reporting Schedule Information, Software Engineering Institute, September 1992 [13] Robert Park, Software Size Measurement: A Framework for Counting Source Statements, Software Engineering Institute, September 1992 [14] History of Functional Size Measurement, Common Software Measurement International Consortium, August

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

Myths and Strategies of Defect Causal Analysis

Myths and Strategies of Defect Causal Analysis Proceedings: Pacific Northwest Software Quality Conference, October 2006 Myths and Strategies of Defect Causal Analysis David N. Card Q-Labs, Inc. dca@q-labs.com Biography David N. Card is a fellow of

More information

Status Report: Practical Software Measurement

Status Report: Practical Software Measurement Status Report: Practical Software David N. Card, Software Productivity Consortium Cheryl L. Jones, US Army card@software.org Abstract This article summarizes the basic concepts of Practical Software (PSM),

More information

Measurement of Object-Oriented Software Development Projects. January 2001

Measurement of Object-Oriented Software Development Projects. January 2001 Measurement of Object-Oriented Software Development Projects January 2001 Principal Authors David N. Card, Software Productivity Consortium Khaled El Emam, National Research Council of Canada Betsy Scalzo,

More information

Using Productivity Measure and Function Points to Improve the Software Development Process

Using Productivity Measure and Function Points to Improve the Software Development Process Using Productivity Measure and Function Points to Improve the Software Development Process Eduardo Alves de Oliveira and Ricardo Choren Noya Computer Engineering Section, Military Engineering Institute,

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

QSM. How to Quote Small In-Process Modifications to Software. by Michael A. Ross

QSM. How to Quote Small In-Process Modifications to Software. by Michael A. Ross QSM Quantitative Software Management, Phoenix Office 5013 West Vogel Avenue Glendale, Arizona 85302 (602) 435-9863 (602) 915-3351 FAX 102121.434@compuserve.com or Michael_A_Ross@msn.com Quoting Small Changes

More information

PMI PMBOK & ESTIMATING PMI PMBOK & ESTIMATING PMI PMBOK & ESTIMATING PMI PMBOK & ESTIMATING PMI PMBOK & ESTIMATING PMI PMBOK & ESTIMATING

PMI PMBOK & ESTIMATING PMI PMBOK & ESTIMATING PMI PMBOK & ESTIMATING PMI PMBOK & ESTIMATING PMI PMBOK & ESTIMATING PMI PMBOK & ESTIMATING PMI PMBOK & ESTIMATING PMI PMBOK & ESTIMATING PMI PMBOK & ESTIMATING PMI PMBOK & ESTIMATING PMI PMBOK & ESTIMATING PMI PMBOK & ESTIMATING 03-23-05 Christine Green, PMI PMBOK and Estimating EDS, Delivery

More information

Toward Quantitative Process Management With Exploratory Data Analysis

Toward Quantitative Process Management With Exploratory Data Analysis Toward Quantitative Process Management With Exploratory Data Analysis Mark C. Paulk Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 Abstract The Capability Maturity Model

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

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

ESTABLISHING A MEASUREMENT PROGRAM

ESTABLISHING A MEASUREMENT PROGRAM ESTABLISHING A MEASUREMENT PROGRAM The most important rule is to Understand that software measurement is a means to an end, not an end in itself Three key reasons for Software Measurement Understanding

More information

TRADITIONAL VS MODERN SOFTWARE ENGINEERING MODELS: A REVIEW

TRADITIONAL VS MODERN SOFTWARE ENGINEERING MODELS: A REVIEW Year 2014, Vol. 1, issue 1, pp. 49-56 Available online at: http://journal.iecuniversity.com TRADITIONAL VS MODERN SOFTWARE ENGINEERING MODELS: A REVIEW Singh RANDEEP a*, Rathee AMIT b a* Department of

More information

Full Function Points for Embedded and Real-Time Software. UKSMA Fall Conference

Full Function Points for Embedded and Real-Time Software. UKSMA Fall Conference Full Function Points for Embedded and Real-Time Software UKSMA Fall Conference London (UK) Oct. 30-31, 1998 Software Engineering Management Research Laboratory Université du Québec à Montréal & Software

More information

CHAPTER 7 Software Configuration Management

CHAPTER 7 Software Configuration Management CHAPTER 7 Software Configuration Management ACRONYMS CCB CM FCA MTBF PCA SCCB SCI SCM SCMP SCR SCSA SEI/CMMI SQA SRS USNRC INTRODUCTION Configuration Control Board Configuration Management Functional Configuration

More information

Quality Management. Lecture 12 Software quality management

Quality Management. Lecture 12 Software quality management Quality Management Lecture 12 Software quality management doc.dr.sc. Marko Jurčević prof.dr.sc. Roman Malarić University of Zagreb Faculty of Electrical Engineering and Computing Department of Fundamentals

More information

Lecture 1: Introduction to Software Quality Assurance

Lecture 1: Introduction to Software Quality Assurance Lecture 1: Introduction to Software Quality Assurance Software Quality Assurance (INSE 6260/4-UU) Winter 2009 Thanks to Rachida Dssouli for some slides Course Outline Software Quality Overview Software

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

Risk Knowledge Capture in the Riskit Method

Risk Knowledge Capture in the Riskit Method Risk Knowledge Capture in the Riskit Method Jyrki Kontio and Victor R. Basili jyrki.kontio@ntc.nokia.com / basili@cs.umd.edu University of Maryland Department of Computer Science A.V.Williams Building

More information

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

Domain Analysis for the Reuse of Software Development Experiences 1

Domain Analysis for the Reuse of Software Development Experiences 1 Domain Analysis for the Reuse of Software Development Experiences 1 V. R. Basili*, L. C. Briand**, W. M. Thomas* * Department of Computer Science University of Maryland College Park, MD, 20742 USA ** CRIM

More information

Improving Software Development Economics Part II: Reducing Software Product Complexity and Improving Software Processes

Improving Software Development Economics Part II: Reducing Software Product Complexity and Improving Software Processes Improving Software Development Economics Part II: Reducing Software Product Complexity and Improving Software Processes by Walker Royce Vice President and General Manager Strategic Services Rational Software

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, Inc. 10 Bow Street Stoneham, Massachusetts 02180 sgoldfarb@qpmg.com Tel: (781) 438-2692 FAX (781) 438-5549 www.qpmg.com

More information

Rise-Based Peer Reviews Linda Westfall The Westfall Team

Rise-Based Peer Reviews Linda Westfall The Westfall Team Rise-Based Peer Reviews Linda Westfall The Westfall Team lwestfall@westfallteam.com www.westfallteam.com Abstract While the benefits of formal inspections are well documented, in reality, many projects

More information

Improve Your Process With Online Good Practices 1

Improve Your Process With Online Good Practices 1 Improve Your Process With Online Good Practices 1 Karl Wiegers Process Impact www.processimpact.com Most software developers are allergic to paper. As organizations improve their software development and

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

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

CHAPTER 3 THE LOANABLE FUNDS MODEL

CHAPTER 3 THE LOANABLE FUNDS MODEL CHAPTER 3 THE LOANABLE FUNDS MODEL The next model in our series is called the Loanable Funds Model. This is a model of interest rate determination. It allows us to explore the causes of rising and falling

More information

Integrating Lean, Six Sigma, and CMMI. David N. Card dca@q-labs.com

Integrating Lean, Six Sigma, and CMMI. David N. Card dca@q-labs.com Integrating Lean, Six Sigma, and CMMI David N. Card dca@q-labs.com Agenda Problem Statement A Little History Popular Approaches Comparison of Approaches Summary Problem Adoption of Six Sigma and Lean is

More information

MEASURES FOR EXCELLENCE SIZING AND CONTROLLING INCREMENTAL SOFTWARE DEVELOPMENT

MEASURES FOR EXCELLENCE SIZING AND CONTROLLING INCREMENTAL SOFTWARE DEVELOPMENT Quantitative Software Management MEASURES FOR EXCELLENCE SIZING AND CONTROLLING INCREMENTAL SOFTWARE DEVELOPMENT J. Greene QSM Ltd 5 Haarlem Road Brook Green PAPER96 Page 1 London W14 0JL Tel : 44-171-603-9009

More information

Best Practices in Model Development and Maintenance Adam Rose (adam.rose@xpsolutions.com), Product Manager, XP Solutions

Best Practices in Model Development and Maintenance Adam Rose (adam.rose@xpsolutions.com), Product Manager, XP Solutions Best Practices in Model Development and Maintenance Adam Rose (adam.rose@xpsolutions.com), Product Manager, XP Solutions adopted from Best practices for software development projects Mike Perks (mperks@us.ibm.com),

More information

BT s supply chain carbon emissions a report on the approach and methodology

BT s supply chain carbon emissions a report on the approach and methodology BT s supply chain carbon emissions a report on the approach and methodology April 2015 1 BT s supply chain emissions metrics approach and methodology 1 Are supply chain emissions really the essential,

More information

ISO, CMMI and PMBOK Risk Management: a Comparative Analysis

ISO, CMMI and PMBOK Risk Management: a Comparative Analysis ISO, CMMI and PMBOK Risk Management: a Comparative Analysis Cristine Martins Gomes de Gusmão Federal University of Pernambuco / Informatics Center Hermano Perrelli de Moura Federal University of Pernambuco

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

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

Software Project Management Matrics. Complied by Heng Sovannarith heng_sovannarith@yahoo.com Software Project Management Matrics Complied by Heng Sovannarith heng_sovannarith@yahoo.com Introduction Hardware is declining while software is increasing. Software Crisis: Schedule and cost estimates

More information

Article 3, Dealing with Reuse, explains how to quantify the impact of software reuse and commercial components/libraries on your estimate.

Article 3, Dealing with Reuse, explains how to quantify the impact of software reuse and commercial components/libraries on your estimate. Estimating Software Costs This article describes the cost estimation lifecycle and a process to estimate project volume. Author: William Roetzheim Co-Founder, Cost Xpert Group, Inc. Estimating Software

More information

Software Development and Testing: A System Dynamics Simulation and Modeling Approach

Software Development and Testing: A System Dynamics Simulation and Modeling Approach Software Development and Testing: A System Dynamics Simulation and Modeling Approach KUMAR SAURABH IBM India Pvt. Ltd. SA-2, Bannerghatta Road, Bangalore. Pin- 560078 INDIA. Email: ksaurab5@in.ibm.com,

More information

Buy versus Build Considerations for Clients Purchasing CLO Dashboard

Buy versus Build Considerations for Clients Purchasing CLO Dashboard Buy versus Build Considerations for Clients Purchasing CLO Dashboard Prepared by Zeroed-In Technologies for use by clients evaluating CLO Dashboard against their internal development of similar executive

More information

What makes a good process?

What makes a good process? Rob Davis Everyone wants a good process. Our businesses would be more profitable if we had them. But do we know what a good process is? Would we recognized one if we saw it? And how do we ensure we can

More information

Eight Practical Tips To Improve Configuration Management

Eight Practical Tips To Improve Configuration Management Eight Practical Tips To Improve Configuration Management By Rich Schiesser: In conjunction with Harris Kern s Enterprise Computing Institute This article discusses an activity that is one of the least

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

IS YOUR DATA WAREHOUSE SUCCESSFUL? Developing a Data Warehouse Process that responds to the needs of the Enterprise.

IS YOUR DATA WAREHOUSE SUCCESSFUL? Developing a Data Warehouse Process that responds to the needs of the Enterprise. IS YOUR DATA WAREHOUSE SUCCESSFUL? Developing a Data Warehouse Process that responds to the needs of the Enterprise. Peter R. Welbrock Smith-Hanley Consulting Group Philadelphia, PA ABSTRACT Developing

More information

Moving from ISO9000 to the Higher Levels of the Capability Maturity Model (CMM)

Moving from ISO9000 to the Higher Levels of the Capability Maturity Model (CMM) Moving from ISO9000 to the Higher Levels of the Capability Maturity Model (CMM) Pankaj Jalote 1 Infosys Technologies Ltd. Bangalore 561 229 Fax: +91-512-590725/590413 Jalote@iitk.ernet.in, jalote@iitk.ac.in

More information

GE Capital Measuring success: Creating metrics that deliver the information you need

GE Capital Measuring success: Creating metrics that deliver the information you need Measuring success: Creating metrics that deliver the information you need viewpoint Measuring success: Creating metrics that deliver the information you need Performance metrics can drive accountability

More information

Button, Button, Whose got the Button?

Button, Button, Whose got the Button? ,, Whose got the?,, Whose got the? (Patterns for breaking client/server relationships) By Robert C. Martin Introduction How many design patterns does it take to turn on a table lamp? This question was

More information

Anatomy of an Enterprise Software Delivery Project

Anatomy of an Enterprise Software Delivery Project Chapter 2 Anatomy of an Enterprise Software Delivery Project Chapter Summary I present an example of a typical enterprise software delivery project. I examine its key characteristics and analyze specific

More information

Lecture Slides for Managing and Leading Software Projects. Chapter 1: Introduction

Lecture Slides for Managing and Leading Software Projects. Chapter 1: Introduction Lecture Slides for Managing and Leading Software Projects Chapter 1: Introduction developed by Richard E. (Dick) Fairley, Ph.D. to accompany the text Managing and Leading Software Projects published by

More information

Calculating utilization in a services company

Calculating utilization in a services company Calculating utilization in a services company This white paper discusses the various approaches to calculating utilization, best practices, and how you can use your professional services automation (PSA)

More information

A Quagmire of Terminology: Verification & Validation, Testing, and Evaluation*

A Quagmire of Terminology: Verification & Validation, Testing, and Evaluation* From: FLAIRS-01 Proceedings. Copyright 2001, AAAI (www.aaai.org). All rights reserved. A Quagmire of Terminology: Verification & Validation, Testing, and Evaluation* Valerie Barr Department of Computer

More information

Name of pattern types 1 Process control patterns 2 Logic architectural patterns 3 Organizational patterns 4 Analytic patterns 5 Design patterns 6

Name of pattern types 1 Process control patterns 2 Logic architectural patterns 3 Organizational patterns 4 Analytic patterns 5 Design patterns 6 The Researches on Unified Pattern of Information System Deng Zhonghua,Guo Liang,Xia Yanping School of Information Management, Wuhan University Wuhan, Hubei, China 430072 Abstract: This paper discusses

More information

SWEBOK Certification Program. Software Engineering Management

SWEBOK Certification Program. Software Engineering Management SWEBOK Certification Program Software Engineering Management Copyright Statement Copyright 2011. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted

More information

Personal Software Process (PSP)

Personal Software Process (PSP) Personal Software Process (PSP) Application of CMM principles to individuals Developed by Watts Humphrey of the Software Engineering Institute (SEI) in the early 1990s Extensive supporting materials: books,

More information

Veterinary Practice Management

Veterinary Practice Management Veterinary Practice Management Inventory Management for Veterinary Practices Although it plays a critical role in any business, inventory management is a task that is often handled ineffectively in veterinary

More information

THE VALUATION OF ADVANCED MINING PROJECTS & OPERATING MINES: MARKET COMPARABLE APPROACHES. Craig Roberts National Bank Financial

THE VALUATION OF ADVANCED MINING PROJECTS & OPERATING MINES: MARKET COMPARABLE APPROACHES. Craig Roberts National Bank Financial THE VALUATION OF ADVANCED MINING PROJECTS & OPERATING MINES: MARKET COMPARABLE APPROACHES Craig Roberts National Bank Financial ABSTRACT While various methods are available to estimate a mining project

More information

Management Accounting 305 Return on Investment

Management Accounting 305 Return on Investment Management Accounting 305 Return on Investment Profit or net income without question is a primary goal of any business. Any business that fails to be profitable in the long run will not survive or will

More information

MEASURING SOFTWARE FUNCTIONAL SIZE FROM BUSINESS PROCESS MODELS

MEASURING SOFTWARE FUNCTIONAL SIZE FROM BUSINESS PROCESS MODELS International Journal of Software Engineering and Knowledge Engineering World Scientific Publishing Company MEASURING SOFTWARE FUNCTIONAL SIZE FROM BUSINESS PROCESS MODELS CARLOS MONSALVE CIDIS-FIEC, Escuela

More information

REDUCING UNCERTAINTY IN SOLAR ENERGY ESTIMATES

REDUCING UNCERTAINTY IN SOLAR ENERGY ESTIMATES REDUCING UNCERTAINTY IN SOLAR ENERGY ESTIMATES Mitigating Energy Risk through On-Site Monitoring Marie Schnitzer, Vice President of Consulting Services Christopher Thuman, Senior Meteorologist Peter Johnson,

More information

1-04-10 Configuration Management: An Object-Based Method Barbara Dumas

1-04-10 Configuration Management: An Object-Based Method Barbara Dumas 1-04-10 Configuration Management: An Object-Based Method Barbara Dumas Payoff Configuration management (CM) helps an organization maintain an inventory of its software assets. In traditional CM systems,

More information

The Role of Function Points in Software Development Contracts

The Role of Function Points in Software Development Contracts The Role of Function Points in Software Development Contracts Paul Radford and Robyn Lawrie, CHARISMATEK Software Metrics info@charismatek.com Abstract Software development contracts often lead to disputes

More information

Mechanics of Currency Hedged Indices

Mechanics of Currency Hedged Indices EQUITY 101 Global Mechanics of Currency Hedged Indices CONTRIBUTORS Sabrina Salemi Manager, Strategy and Global Equity Indices sabrina.salemi@spdji.com Philip Murphy, CFA Vice President, North American

More information

(Refer Slide Time: 01:52)

(Refer Slide Time: 01:52) Software Engineering Prof. N. L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture - 2 Introduction to Software Engineering Challenges, Process Models etc (Part 2) This

More information

TAGUCHI APPROACH TO DESIGN OPTIMIZATION FOR QUALITY AND COST: AN OVERVIEW. Resit Unal. Edwin B. Dean

TAGUCHI APPROACH TO DESIGN OPTIMIZATION FOR QUALITY AND COST: AN OVERVIEW. Resit Unal. Edwin B. Dean TAGUCHI APPROACH TO DESIGN OPTIMIZATION FOR QUALITY AND COST: AN OVERVIEW Resit Unal Edwin B. Dean INTRODUCTION Calibrations to existing cost of doing business in space indicate that to establish human

More information

Outcome-Driven Customer Experience

Outcome-Driven Customer Experience Maximizing Value As the global economy recovers and the next era of economic growth begins, results not efforts are expected in the corporate boardroom. Conservative consumer spending and tight competitive

More information

Software Engineering Reference Framework

Software Engineering Reference Framework Software Engineering Reference Framework Michel Chaudron, Jan Friso Groote, Kees van Hee, Kees Hemerik, Lou Somers, Tom Verhoeff. Department of Mathematics and Computer Science Eindhoven University of

More information

REQUIREMENTS SPECIFICATION AND MANAGEMENT. Requirements Analysis and Specification

REQUIREMENTS SPECIFICATION AND MANAGEMENT. Requirements Analysis and Specification REQUIREMENTS SPECIFICATION AND MANAGEMENT In this note we give the requirements process in a software organization, a template for the requirements document, and the process to manage changes to the requirements.

More information

Managing Portfolios of DSM Resources and Reducing Regulatory Risks: A Case Study of Nevada

Managing Portfolios of DSM Resources and Reducing Regulatory Risks: A Case Study of Nevada Managing Portfolios of DSM Resources and Reducing Regulatory Risks: A Case Study of Nevada Hossein Haeri, Lauren Miller Gage, and Amy Green, Quantec, LLC Larry Holmes, Nevada Power Company/Sierra Pacific

More information

Requirements-Based Testing: Encourage Collaboration Through Traceability

Requirements-Based Testing: Encourage Collaboration Through Traceability White Paper Requirements-Based Testing: Encourage Collaboration Through Traceability Executive Summary It is a well-documented fact that incomplete, poorly written or poorly communicated requirements are

More information

Robert and Mary Sample

Robert and Mary Sample Comprehensive Financial Plan Sample Plan Robert and Mary Sample Prepared by : John Poels, ChFC, AAMS Senior Financial Advisor February 11, 2009 Table Of Contents IMPORTANT DISCLOSURE INFORMATION 1-7 Presentation

More information

Performance Measurement

Performance Measurement Performance Measurement Introduction Performance measurement is a fundamental building block of TQM and a tal quality organisation. Hisrically, organisations have always measured performance in some way

More information

Mining the Software Change Repository of a Legacy Telephony System

Mining the Software Change Repository of a Legacy Telephony System Mining the Software Change Repository of a Legacy Telephony System Jelber Sayyad Shirabad, Timothy C. Lethbridge, Stan Matwin School of Information Technology and Engineering University of Ottawa, Ottawa,

More information

Getting More From Your Actuarial Analysis

Getting More From Your Actuarial Analysis Getting More From Your Actuarial Analysis For Companies Retaining Property/Casualty Insurance Risks PwC 1 Introduction Many companies retain property/casualty insurance (P&C) risks, such as workers' compensation,

More information

Software project cost estimation using AI techniques

Software project cost estimation using AI techniques Software project cost estimation using AI techniques Rodríguez Montequín, V.; Villanueva Balsera, J.; Alba González, C.; Martínez Huerta, G. Project Management Area University of Oviedo C/Independencia

More information

How Rational Configuration and Change Management Products Support the Software Engineering Institute's Software Capability Maturity Model

How Rational Configuration and Change Management Products Support the Software Engineering Institute's Software Capability Maturity Model How Rational Configuration and Change Management Products Support the Software Engineering Institute's Software Capability Maturity Model by Bill Cottrell and John Viehweg Software Engineering Specialists

More information

NCOE whitepaper Master Data Deployment and Management in a Global ERP Implementation

NCOE whitepaper Master Data Deployment and Management in a Global ERP Implementation NCOE whitepaper Master Data Deployment and Management in a Global ERP Implementation Market Offering: Package(s): Oracle Authors: Rick Olson, Luke Tay Date: January 13, 2012 Contents Executive summary

More information

Software Metrics & Software Metrology. Alain Abran. Chapter 4 Quantification and Measurement are Not the Same!

Software Metrics & Software Metrology. Alain Abran. Chapter 4 Quantification and Measurement are Not the Same! Software Metrics & Software Metrology Alain Abran Chapter 4 Quantification and Measurement are Not the Same! 1 Agenda This chapter covers: The difference between a number & an analysis model. The Measurement

More information

International Association of Scientific Innovation and Research (IASIR) (An Association Unifying the Sciences, Engineering, and Applied Research)

International Association of Scientific Innovation and Research (IASIR) (An Association Unifying the Sciences, Engineering, and Applied Research) International Association of Scientific Innovation and Research (IASIR) (An Association Unifying the Sciences, Engineering, and Applied Research) International Journal of Engineering, Business and Enterprise

More information

www.transition-support.com

www.transition-support.com Can we include all products and services in the QMS but limit the scope of registration? According to ISO/TC 176/SC 2/N 524, organizations are not obliged to include all the products that it provides within

More information

Much attention has been focused recently on enterprise risk management (ERM),

Much attention has been focused recently on enterprise risk management (ERM), By S. Michael McLaughlin and Karen DeToro Much attention has been focused recently on enterprise risk management (ERM), not just in the insurance industry but in other industries as well. Across all industries,

More information

A Software Development Simulation Model of a Spiral Process

A Software Development Simulation Model of a Spiral Process A Software Development Simulation Model of a Spiral Process ABSTRACT: There is a need for simulation models of software development processes other than the waterfall because processes such as spiral development

More information

Partnering for Project Success: Project Manager and Business Analyst Collaboration

Partnering for Project Success: Project Manager and Business Analyst Collaboration Partnering for Project Success: Project Manager and Business Analyst Collaboration By Barbara Carkenord, CBAP, Chris Cartwright, PMP, Robin Grace, CBAP, Larry Goldsmith, PMP, Elizabeth Larson, PMP, CBAP,

More information

Why process models? Topic 3 Software process models. 3. Process models. What is a process model?

Why process models? Topic 3 Software process models. 3. Process models. What is a process model? Why process models? Topic 3 Software process models SE is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software... (IEEE Standard

More information

Measuring ALL the Software not just what the Business Uses

Measuring ALL the Software not just what the Business Uses Measuring ALL the Software not just what the Business Uses Pam Morris and Jean-Marc Desharnais Total Metrics and SELAM Function Point Analysis (FPA) is used by organisations worldwide as one of the measures

More information

Assessing Software Productivity with An Estimation Model: A Case Study. Elizabeth A. Miller, Galorath Incorporated

Assessing Software Productivity with An Estimation Model: A Case Study. Elizabeth A. Miller, Galorath Incorporated Assessing Software Productivity with An Estimation Model: A Case Study Elizabeth A. Miller, Galorath Incorporated Trade publications in the software field as well as the popular media are filled with articles

More information

How to Write a Software Process Procedures and Policy Manual for YOUR COMPANY

How to Write a Software Process Procedures and Policy Manual for YOUR COMPANY How to Write a Software Process for YOUR COMPANY 1. Introduction MicroTools is proposing to assist YOUR COMPANY in improving the existing software process. The purpose of this project is to both improve

More information

Measurement for Successful Projects. Authored by Michael Harris and David Herron

Measurement for Successful Projects. Authored by Michael Harris and David Herron Measurement for Successful Projects Authored by Michael Harris and David Herron Software Project Managers have many responsibilities ranging from managing customer expectations to directing internal resources

More information

Industry Environment and Concepts for Forecasting 1

Industry Environment and Concepts for Forecasting 1 Table of Contents Industry Environment and Concepts for Forecasting 1 Forecasting Methods Overview...2 Multilevel Forecasting...3 Demand Forecasting...4 Integrating Information...5 Simplifying the Forecast...6

More information

SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT

SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT Mar 31, 2014 Japan Aerospace Exploration Agency This is an English translation of JERG-2-610. Whenever there is anything ambiguous in this document, the original

More information

The Phases of an Object-Oriented Application

The Phases of an Object-Oriented Application The Phases of an Object-Oriented Application Reprinted from the Feb 1992 issue of The Smalltalk Report Vol. 1, No. 5 By: Rebecca J. Wirfs-Brock There is never enough time to get it absolutely, perfectly

More information

Five Levels of Project Portfolio Management

Five Levels of Project Portfolio Management Five Levels of Project Portfolio Management Figure 49 summarizes five levels of project portfolio management maturity [1]. Each level represents the adoption of an increasingly comprehensive and effective

More information

Measuring Lending Profitability at the Loan Level: An Introduction

Measuring Lending Profitability at the Loan Level: An Introduction FINANCIAL P E RF O R MA N C E Measuring Lending Profitability at the Loan Level: An Introduction sales@profitstars.com 877.827.7101 How much am I making on this deal? has been a fundamental question posed

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

Studying Code Development for High Performance Computing: The HPCS Program

Studying Code Development for High Performance Computing: The HPCS Program Studying Code Development for High Performance Computing: The HPCS Program Jeff Carver 1, Sima Asgari 1, Victor Basili 1,2, Lorin Hochstein 1, Jeffrey K. Hollingsworth 1, Forrest Shull 2, Marv Zelkowitz

More information

M & V Guidelines for HUD Energy Performance Contracts Guidance for ESCo-Developed Projects 1/21/2011

M & V Guidelines for HUD Energy Performance Contracts Guidance for ESCo-Developed Projects 1/21/2011 M & V Guidelines for HUD Energy Performance Contracts Guidance for ESCo-Developed Projects 1/21/2011 1) Purpose of the HUD M&V Guide This document contains the procedures and guidelines for quantifying

More information

USING SECURITY METRICS TO ASSESS RISK MANAGEMENT CAPABILITIES

USING SECURITY METRICS TO ASSESS RISK MANAGEMENT CAPABILITIES Christina Kormos National Agency Phone: (410)854-6094 Fax: (410)854-4661 ckormos@radium.ncsc.mil Lisa A. Gallagher (POC) Arca Systems, Inc. Phone: (410)309-1780 Fax: (410)309-1781 gallagher@arca.com USING

More information

Process Models and Metrics

Process Models and Metrics Process Models and Metrics PROCESS MODELS AND METRICS These models and metrics capture information about the processes being performed We can model and measure the definition of the process process performers

More information

Program Life Cycle Cost Driver Model (LCCDM) Daniel W. Miles, General Physics, June 2008

Program Life Cycle Cost Driver Model (LCCDM) Daniel W. Miles, General Physics, June 2008 Program Life Cycle Cost Driver Model (LCCDM) Daniel W. Miles, General Physics, June 28 Introduction Several years ago during the creation of the Periscope Total Ownership Cost (TOC) Program, it became

More information

Domain-specific Engineering

Domain-specific Engineering Domain-specific Engineering Grady H. Campbell, Jr. Prosperity Heights Software 8457 Van Court Annandale, VA 22003 1 703 573 3139 GradyCampbell@acm.org ABSTRACT The development of software today is a craft

More information

DEVELOPING REQUIREMENTS FOR DATA WAREHOUSE SYSTEMS WITH USE CASES

DEVELOPING REQUIREMENTS FOR DATA WAREHOUSE SYSTEMS WITH USE CASES DEVELOPING REQUIREMENTS FOR DATA WAREHOUSE SYSTEMS WITH USE CASES Robert M. Bruckner Vienna University of Technology bruckner@ifs.tuwien.ac.at Beate List Vienna University of Technology list@ifs.tuwien.ac.at

More information

Family Evaluation Framework overview & introduction

Family Evaluation Framework overview & introduction A Family Evaluation Framework overview & introduction P B Frank van der Linden O Partner: Philips Medical Systems Veenpluis 4-6 5684 PC Best, the Netherlands Date: 29 August, 2005 Number: PH-0503-01 Version:

More information

How to Define SIEM Strategy, Management and Success in the Enterprise

How to Define SIEM Strategy, Management and Success in the Enterprise How to Define SIEM Strategy, Management and Success in the Enterprise Security information and event management (SIEM) projects continue to challenge enterprises. The editors at SearchSecurity.com have

More information