CSSE 372 Software Project Management: Software Estimation With COCOMO-II

Similar documents
Software cost estimation. Predicting the resources required for a software development process

Chapter 23 Software Cost Estimation

Software cost estimation

CISC 322 Software Architecture

MTAT Software Economics. Lecture 5: Software Cost Estimation

Software cost estimation

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

Software cost estimation

2 Evaluation of the Cost Estimation Models: Case Study of Task Manager Application. Equations

COCOMO II and Big Data

CISC 322 Software Architecture. Example of COCOMO-II Ahmed E. Hassan

The COCOMO II Estimating Model Suite

COCOMO II Model Definition Manual

University of Southern California COCOMO Reference Manual

Cost Estimation Driven Software Development Process

Software Migration Project Cost Estimation using COCOMO II and Enterprise Architecture Modeling

Cost Models for Future Software Life Cycle Processes: COCOMO 2.0 *

Extending Change Impact Analysis Approach for Change Effort Estimation in the Software Development Phase

Project Plan. Online Book Store. Version 1.0. Vamsi Krishna Mummaneni. CIS 895 MSE Project KSU. Major Professor. Dr.Torben Amtoft

COCOMO (Constructive Cost Model)

Fuzzy Expert-COCOMO Risk Assessment and Effort Contingency Model in Software Project Management

COCOMO-SCORM Interactive Courseware Project Cost Modeling

Contents. Today Project Management. Project Management. Last Time - Software Development Processes. What is Project Management?

COCOMO II Model Definition Manual

Finally, Article 4, Creating the Project Plan describes how to use your insight into project cost and schedule to create a complete project plan.

Project Plan 1.0 Airline Reservation System

Keywords Software Cost; Effort Estimation, Constructive Cost Model-II (COCOMO-II), Hybrid Model, Functional Link Artificial Neural Network (FLANN).

CS Homework 4 p. 1. CS Homework 4. To become more familiar with top-down effort estimation models, especially COCOMO 81 and COCOMO II.

Incorporating Data Mining Techniques on Software Cost Estimation: Validation and Improvement

Comparative Analysis of COCOMO II, SEER-SEM and True-S Software Cost Models

SOFTWARE COST DRIVERS AND COST ESTIMATION IN NIGERIA ASIEGBU B, C AND AHAIWE, J

Web Development: Estimating Quick-to-Market Software

Agile Inspired Risk Mitigation Techniques for Software Development Projects

USC COCOMO. Reference Manual. University of Southern California

Effect of Schedule Compression on Project Effort

Project Planning and Project Estimation Techniques. Naveen Aggarwal

Software Engineering. Dilbert on Project Planning. Overview CS / COE Reading: chapter 3 in textbook Requirements documents due 9/20

Deducing software process improvement areas from a COCOMO II-based productivity measurement

Software Engineering. Reading. Effort estimation CS / COE Finish chapter 3 Start chapter 5

AN ENHANCED MODEL TO ESTIMATE EFFORT, PERFORMANCE AND COST OF THE SOFTWARE PROJECTS

Identifying Factors Affecting Software Development Cost

A Comparative Evaluation of Effort Estimation Methods in the Software Life Cycle

E-COCOMO: The Extended COst Constructive MOdel for Cleanroom Software Engineering

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

Software Engineering Cost Estimation Using COCOMO II Model ABSTRACT

Knowledge-Based Systems Engineering Risk Assessment

Lecture 14: Cost Estimation

This past year, electronic commerce

Software Cost Estimation: A Tool for Object Oriented Console Applications

VIDYAVAHINI FIRST GRADE COLLEGE

CSSE 372 Software Project Management: Software Risk Management

The role of Software Metrics on Software Development Life Cycle

Artificial Neural Networks for Software Effort Estimation: A Review

Algorithms, Flowcharts & Program Design. ComPro

Software Engineering Question Bank

SEER for Software - Going Beyond Out of the Box. David DeWitt Director of Software and IT Consulting

Software Development: Tools and Processes. Lecture - 16: Estimation

IMPROVED SIZE AND EFFORT ESTIMATION MODELS FOR SOFTWARE MAINTENANCE. Vu Nguyen

Module 11. Software Project Planning. Version 2 CSE IIT, Kharagpur

TYPICAL QUESTIONS & ANSWERS

Unit 9: Software Economics

Company Setup 401k Tab

Fundamentals of Measurements

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

SIZE & ESTIMATION OF DATA WAREHOUSE SYSTEMS

The software maintenance project effort estimation model based on function points

When To Work Scheduling Program

Dr. Barry W. Boehm USC Center for Software Engineering

Safety critical software and development productivity

Software Engineering. System Models. Based on Software Engineering, 7 th Edition by Ian Sommerville

Comparison of SDLC-2013 Model with Other SDLC Models by Using COCOMO

Acknowledgement. Software Engineering. CS 3141: Team Software Project Introduction

The 10 Most Important Ideas in Software Development

How To Develop Software

Software Project Planning - The Relationship between Project Planning and Project Success.

WBS, Estimation and Scheduling. Adapted from slides by John Musser

Software Cost Estimation Methods: A Review

ICS 121 Lecture Notes Spring Quarter 96

Towards a Methodology to Estimate Cost of Object- Oriented Software Development Projects

Estimating Size and Effort

Lecture 1: Introduction to Software Quality Assurance

10 Keys to Successful Software Projects: An Executive Guide

Amplification of the COCOMO II regarding Offshore Software Projects

CSSE 372 Software Project Management: Earned Value Analysis (EVA) Exercises

Software Intensive Systems Cost and Schedule Estimation

Cost Estimation for Secure Software & Systems

An Intelligent Approach to Software Cost Prediction

Software Cost Estimating. Acknowledgments

CSSE 372 Software Project Management: Software Project Work Breakdown Structures

Software Cost Estimation

Appointment reminders (template based, sent automatically)

Transcription:

CSSE 372 Software Project Management: Software Estimation With COCOMO-II Shawn Bohner Office: Moench Room F212 Phone: (812) 877-8685 Email: bohner@rose-hulman.edu

Estimation Experience and Beware of the Sales Guy Yikes!

Cost Estimation n Project scope must be explicitly defined n Task, functional, or component decomposition is necessary n Historical measures (metrics) are very helpful n To assure fit, use two or more estimation techniques n Uncertainty is inherent in most estimation endeavors plan on it!

Learning Outcomes: Estimation Estimate software project effort, cost, and schedule for an intermediate size project. n Outline the COCOMO-II parametric model as an example n Examine the key factors and adjustments n Walk through getting started

Constructive Cost Model (COCOMO) n Empirical model based on project experience n Well-documented, independent model, Independent of a specific software vendor n Long history initially published in 1981 (COCOMO-81) and last in 1999 (COCOMO-II) n COCOMO-II takes into account different approaches to software development, reuse, etc.

Accommodating Progression Three-level model that allows increasingly detailed estimates to be prepared as development progresses n Early prototyping level Based on object points Simple formula n Early design level Based on function points that are then translated to lines of source code (LOC) n Post-architecture level Estimates based on LOC Q1

Early Prototyping Level n Supports prototyping projects and projects where there is extensive reuse n Estimates effort in object points/staff month n PM = ( NOP (1 - %reuse/100 ) ) / PROD, where: PM is the effort in person-months NOP is the number of object points PROD is the productivity Q2

Early Design Level n Estimates made after requirements confirmed!!pm = A Size B M + πem i where: n A = 2.5 in initial calibration n Size in KLOC n B varies from 1.1 to 1.24 depending on novelty of project, development flexibility, risk management approaches, and process maturity n EM = (ASLOC (AT / 100) ) / ATPROD n M = PERS RCPX RUSE PDIF PREX FCIL SCED n I = 1 Q3

Multipliers Multipliers reflect capability of developers, nonfunctional requirements, familiarity with development platform, etc. RCPX - product reliability and complexity RUSE - the reuse required PDIF - platform difficulty PREX - personnel experience PERS - personnel capability SCED - required schedule FCIL - the team support facilities

Post-Architecture Level n Uses same formula as early design estimates n Estimate of size adjusted to account for: Requirements volatility Rework required to support change Extent of possible reuse Q4

Post-Architecture Level (continued) ESLOC = ASLOC x (AA + SU +0.4DM + 0.3CM + 0.3IM) / 100 n ESLOC is equivalent number of lines of new code n ASLOC is the adjusted number of lines of reusable code which must be modified n DM is the % of design modified n CM is the % of the code that is modified n IM is the % of the original integration effort required for integrating the reused software n SU is a factor based on the cost of software understanding n AA is a factor which reflects the initial assessment costs of deciding if software may be reused

Exponent Scale Factors Scale factor Precedentedness Development flexibility Architecture/risk resolution Team cohesion Process maturity Explanation Reflects the previous experience of the organization with this type of project. Very low means no previous experience, Extra high means that the organization is completely familiar with this application domain. Reflects the degree of flexibility in the development process. Very low means a prescribed process is used; Extra high means that the client only sets general goals. Reflects the extent of risk analysis carried out. Very low means little analysis, Extra high means a complete a thorough risk analysis. Reflects how well the development team know each other and work together. Very low means very difficult interactions, Extra high means an integrated and effective team with no communication problems. Reflects the process maturity of the organization. The computation of this value depends on the CMM Maturity Questionnaire but an estimate can be achieved by subtracting the CMM process maturity level from 5. Q5

Project Cost Drivers Product attributes RELY Required system DATA Size of database used reliability CPLX Complexity of system modules RUSE Required percentage of reusable components DOCU Extent of documentation required Computer attributes TIME Execution time STOR Memory constraints constraints PVOL Volatility of development platform Personnel attributes ACAP Capability of project PCAP Programmer capability analysts PCON Personnel continuity AEXP Analyst experience in project domain PEXP Programmer experience LTEX Language and tool experience in project domain Project attributes TOOL Use of software tools SITE Extent of multi-site working and quality of site communications SCED Development schedule compression Q6

What the Cocomo II screen looks like upon starting a new Project. Note you start out in the Post Architecture model, and there is no Application Composition model available.

Enter a Project Name

Can t really do much unless we add a Module, so choose Edit à Add Module. A new line shows up in the screen with a default module name.

1. Change the module name to whatever you want. 2. Now double click on the yellow rectangle under Module Size

This screen will pop up allowing us to choose between Source Lines Of Code (SLOC), Function Points, or Adaptation and Re-Use. Let s stick with SLOC for this module.

The program language is C++ (this is really important to know for Function Points), there is an estimated 10,000 lines of code, and 20% of the code will be discarded due to requirements evolution and volatility. Hit OK

The main screen is updated with the SLOC and programming language as well as some calculated values we will decipher later. Note that the SLOC is 12,000. Why? J {Pertinent portion of calculation on next slide in red boxes} Now add another module and choose Function Points.

COCOMO-II Calculations: Effort Equation for Post Architecture Model

This is the default screen for Function Points. Let s look deeper at the Function Type descriptions

External Input (Inputs) External Output (Outputs) Count each unique user data or user control input type that (i) enters the external boundary of the software system being measured and (ii) adds or changes data in a logical internal file. Count each unique user data or control output type that leaves the external boundary of the software system being measured. Internal Logical File (Files) External Interface Files (Interfaces) Count each major logical group of user data or control information in the software system as a logical internal file type. Include each logical file (e.g., each logical group of data) that is generated, used, or maintained by the software system. Files passed or shared between software systems should be counted as external interface file types within each system. External Inquiry (Queries) Count each unique input-output combination, where an input causes and generates an immediate output, as an external inquiry type. From Cocomo II User Manual via software

So let s go back into this screen and add some entries in the grid. Notice, there are some kind of subtotals per line, but the Equivalent SLOC = 0. Let s change the Language and see what happens.

By changing the language to C++, we now have an Equivalent Total in SLOC. Also, we can see a value next to the Change Multiplier button. Let s change the language to Machine Code! J

Quite a difference jumping from 10,653 SLOC to 128,640 SLOC. Note the multiplier changed from 53 to 640. Change the language once more to 5th Generation.

So using a 5th generation level language would cut our code base by a factor of 285 times according to COCOMO II s default estimation (not calibrated for your environment, not taking into account other factors). Change the language to C++ and change REVL to 20%

So now Module2 has F:12783 or, in other words, it s based on Function points (the F:) and it has an equivalent 12,783 lines of code (10,653 + 20% for volatility). So how did the 12,783 (or even the 10,653) get calc d? Part 1 of the answer is to click on Parameters à Function Points. You will see the following screen Q7

These are the default values used as weighting factors against the entries you put in. So if you entered 2,3,4 when enter in Function Point information for the first row, the end result would be 2*7 + 3*10 + 4*15. This is then multiplied by The Change Multiplier

Triangulation on Estimation Method Results Each Estimation Method has strengths and weaknesses need to offset. Size Estimate Choose Estimation Methods Define Environmental Parameters Estimation Method 1 (M1) Estimation Method 2 (M2) Note: Estimates within 20% are acceptable in the early phases of a project < + - 20% M1 - M2 > + - 20% Continue Estimation Process Investigate discrepancies between the 2 estimates.

Homework and Reading Reminders n Read Paper for Thursday s Case Study n Complete Homework 3 Software Estimate Using COCOMO-II or Costar Due by 5pm, Tuesday, September 25 th, 2012