CS 551 Estimation Fall 2005 1 December 2005. QSE Lambda Protocol Prospectus Measurable Operational Value Prototyping or Modeling sQFD Schedule, Staffing,

Slides:



Advertisements
Similar presentations
FPA – IFPUG CPM 4.1 Rules.
Advertisements

Early Effort Estimation of Business Data-processing Enhancements CS 689 November 30, 2000 By Kurt Detamore.
Planning a software project: Function point analysis. José Onofre Montesa Andrés Universidad Politécnica de Valencia Escuela Superior de Informática Aplicada.
Lecture 6 Estimation Estimate size, then Estimate effort, schedule and cost from size Bound estimates CS 540 – Quantitative Software Engineering.
Software project management (intro)
1 PROJECT SIZING AND ESTIMATING - EFFECTIVELY USING FUNCTIONAL MEASUREMENT Southern California Software Process Improvement.
Predictive Modeling And Reporting Environment (PMRE) CS 552 Senior Design Architecture Review Presenting: Steve Su Ilya Chalyt Yuriy Stelmakh (Architect)
Lecture 2 Estimation-revisited Estimate size, then Estimate effort, schedule and cost from size Reuse, reuse, reuse CS 552.
Lecture 6 Estimation Estimate size, then Estimate effort, schedule and cost from size CS 540 – Quantitative Software Engineering.
CS 540 – Quantitative Software Engineering
Lecture 5 Estimation-revised Estimate size, then Estimate effort, schedule and cost from size CS 551.
SOFTWARE PROJECT MANAGEMENT AND COST ESTIMATION © University of LiverpoolCOMP 319slide 1.
Information Technology Project Management
1 Cost Estimation CIS 375 Bruce R. Maxim UM-Dearborn.
1 U08784 Software Project Management lecturer: Timothy Au url:
Copyright © The David Consulting Group, Inc. 1 UNDERSTANDING and EFFECTIVELY USING FUNCTIONAL MEASUREMENT Presented By The David Consulting Group.
Project Cost Estimation
Cmpe 589 Spring Software Quality Metrics Product  product attributes –Size, complexity, design features, performance, quality level Process  Used.
COCOMO Models Ognian Kabranov SEG3300 A&B W2004 R.L. Probert.
Estimation Why estimate? What to estimate? When to estimate?
Chapter 6 : Software Metrics
Chapter 6 The Work Breakdown Structure and Project Estimation Copyright 2012 John Wiley & Sons, Inc. 6-1.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 1 Chapter 23 Software Cost Estimation.
Function Point Analysis What is Function Point Analysis (FPA)? It is designed to estimate and measure the time, and thereby the cost, of developing new.
Sizing Your Development Effort Using Function Point Analysis Mike Pasley Logic Central
Personal Estimation with PROBE CS3300 Fall Code Size Estimation Wide Band Delphi (Boehm) Give the team the specs to study Discuss the project goals.
Software cost estimation Predicting the resources required for a software development process 1.
Software Metrics Software Engineering.
1 Estimation Function Point Analysis December 5, 2006.
Lecture 4 Software Metrics
10/27/20151Ian Sommerville.  Fundamentals of software measurement, costing and pricing  Software productivity assessment  The principles of the COCOMO.
Cost Estimation. Problem Our ability to realistically plan and schedule projects depends on our ability to estimate project costs and development efforts.
Software complexity estimation by Adam Bondarowicz by Adam Bondarowicz.
Quality Software Project Management Software Size and Reuse Estimating.
Function Point Analysis. Function Points Analysis (FPA) What is Function Point Analysis (FPA)? Function points are a standard unit of measure that represent.
Introduction to Software Project Estimation I (Condensed) Barry Schrag Software Engineering Consultant MCSD, MCAD, MCDBA Bellevue.
©Ian Sommerville 2000Software Engineering, 7th edition. Chapter 26Slide 1 Software cost estimation l Predicting the resources required for a software development.
©1999 Addison Wesley LongmanSlide 3.1 Managing IS Projects Planning –Decomposing Project into Activities –Estimating resources –Developing a schedule –Setting.
Function Points Synthetic measure of program size used to estimate size early in the project Easier (than lines of code) to calculate from requirements.
Estimating “Size” of Software There are many ways to estimate the volume or size of software. ( understanding requirements is key to this activity ) –We.
Effort Estimation In WBS,one can estimate effort (micro-level) but needed to know: –Size of the deliverable –Productivity of resource in producing that.
Functional Size Measurement Methodologies. What is FSM ? Definitions: Functional Size: A size of the software derived by quantifying the Functional User.
CSE SW Project Management / Module 13 - Function Points and Related Methods Copyright © , Dennis J. Frailey, All Rights Reserved CSE7315M13.
Personal Estimation with PROBE CS3300 Fall Process Everybody has one !!! Formal – Completely defined and documented Informal – Just the way things.
NASA Software Assurance Symposium 2001 Metrics for Fault-Tolerant Real-Time Software Afzel Noore Computer Science and Electrical Engineering West Virginia.
FUNCTION POINT ANALYSIS & ESTIMATION
CS 551 – Requirements. Software Requirements Process l Requirements Elicitation l Requirements Analysis l Use Cases l Requirements Specification l Prototype.
Cost9b 1 Living with Function Points Bernstein and Lubashevsky Text pp
Estimation Questions How do you estimate? What are you going to estimate? Where do you start?
Cost23 1 Question of the Day u Which of the following things measure the “size” of the project in terms of the functionality that has to be provided in.
Copyright , Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M13 - Version 8.01 SMU CSE 7315 Planning and Managing a Software Project.
THE FAMU-CIS ALUMNI SYSTEM
Alternative Software Size Measures for Cost Estimation
The Work Breakdown Structure and Project Estimation
Testing Techniques.
RET Rules One of the following rules applies when counting RETs:
Function Point Analysis
The Work Breakdown Structure and Project Estimation
Software Development & Project Management
Mk II Function Point Analysis
Alternative Software Size Measures for Cost Estimation
Software Size Measures for Cost Estimation
Personal Software Process Software Estimation
Function Point.
Chapter 5: Software effort estimation- part 2
Software Metrics “How do we measure the software?”
More on Estimation In general, effort estimation is based on several parameters and the model ( E= a + b*S**c ): Personnel Environment Quality Size or.
COCOMO Models.
Software Effort Estimation
COCOMO MODEL.
Presentation transcript:

CS 551 Estimation Fall December 2005

QSE Lambda Protocol Prospectus Measurable Operational Value Prototyping or Modeling sQFD Schedule, Staffing, Quality Estimates ICED-T Trade-off Analysis

Requirements Specification Spec 1.Project Title, Revision Number and Author 2.Scope and Purpose of the system 3.Measurable Operational Value 4.Description 5.Feature List including ICED T and Simplified QFD analysis 6.Interfaces 7.Constraints 8.Change Log and Expected Changes 9.Responses to the unexpected 10.Measurements 11.Glossary 12.References

Specification for Development Plan Project Feature List Development Process Size Estimates Staff Estimates Schedule Estimates Organization Gantt Chart

Sizing Software Projects Effort = (productivity) (size) c Staff months Lines of Code or Function Points 500

Lines of Code LOC= Line of Code SLOC = Source Line of Code NCSLOC = New or Changed Source of Lines of Code

Function Points Bell Laboratories data Capers Jones data Productivity (Function points / staff month) Productivity= f(Size)

Bernstein’s rule of thumb Productivity per staff-month: 50 NCSLOC for OS code (or real-time system) 250 NCSLOC for intermediary applications (high risk, on-line) 500 NCSLOC for normal applications (low risk, on-line) 10,000 NCSLOC for reused code Reuse note: Sometimes, reusing code that does not provide the exact functionality needed can be achieved by reformatting input/output. This decreases performance but dramatically shortens development time.

Software Development Productivity for Industry Average Transaction Projects Characteristic Software Development Productivity (SLOC/WM) Classical rates Evolutionary approaches New embedded flight software 17 – 105

Bernstein’s Trends in Software Expansion Small Scale Reuse 1990 Subsec Time Sharing 1995 Object Oriented Programming 1960 Machine Instructions 1965 Macro Assembler 1970 High Level Language 1975 Database Manager 1980 On-line 1985 Prototyping 2000 Large Scale Reuse Regression Testing 4GL Order of Magnitude Every Twenty Years Expansion Factor Technology Change

Function Point Analysis Can use early in project (data from requirements) Substantial data supports the methodology Software Shop and Project characteristics are accounted for in the Adjusted Function Points Technology and Project Methodology dependent Technology changes negate history until the new relative improvement is established Still have to estimate other elements of the project Could be done by converting UFPs to LOC for a specific language (technology) and then using an algorithmic tool such as COCOMO or SLIM.

Adjusted Function Points Accounting for Physical System Characteristics Characteristic Rated by System User 0-5 based on “degree of influence” 3 is average Unadjusted Function Points (UFP) Unadjusted Function Points (UFP) General System Characteristics (GSC) General System Characteristics (GSC) X = Adjusted Function Points (AFP) Adjusted Function Points (AFP) AFP = UFP ( *GSC), note GSC = VAF= TDI 1.Data Communications 2.Distributed Data/Processing 3.Performance Objectives 4.Heavily Used Configuration 5.Transaction Rate 6.On-Line Data Entry 7.End-User Efficiency 8.On-Line Update 9.Complex Processing 10.Reusability 11.Conversion/Installation Ease 12.Operational Ease 13.Multiple Site Use 14.Facilitate Change

Computing Function Points

External Inputs – One updates two files External Inputs (EI) - when data crosses the boundary from outside to inside. This data may come from a data input screen or another application.

External Interface Table For example, EIs that reference or update 2 File Types Referenced (FTR’s) and has 7 data elements would be assigned a ranking of average and associated rating of 4. File Type References (FTR’s) are the sum of Internal Logical Files referenced or updated and External Interface Files referenced.

External Output from 2 Internal Files External Outputs (EO) – when data passes across the boundary from inside to outside.

External Inquiry drawing from 2 ILFs External Inquiry (EQ) - an elementary process with both input and output components that result in data retrieval from one or more internal logical files and external interface files. The input process does not update Internal Logical File, and there is no derived data.

EO and EQ Table mapped to Values

Computing Function Points

Internal Logical Files Internal Logical Files (ILF’s) - a user identifiable group of logically related data that resides entirely within the applications boundary and is maintained through external inputs.

External Interface Files External Interface Files (EIF’s) - a user identifiable group of logically related data that is used for reference purposes only. The data resides entirely outside the application and is maintained by another application. The external interface file is an internal logical file for another application.

Proposed System Check Status Create Order Shipment Notice Inventory Assign Inventory to Order Inventory Assigned New Inventory for Held Orders Assign Order to Truck Truckload Report Shipping Invoices Order Update Order Display Problem Resolution Dispatch Accounting Management Reports Customer Check Credit & Completion Users Catalog Orders Order Creation Credit Check Inventory Assignment Held Order Processing Completion Dispatch Support Problem Resolution Management Reporting OA&M

Case Study: Web Front End

GSC Example: Web Front End

Software Costing Cost Development using FPA Estimate Requirements Engineering (1/3 of implementation Design (1/5 of implementation) Testing (1/4 of implementation Documentation & Training 7.6

Function Points Evaluated AdvantagesDisadvantages Standards are established and reviewed frequently. Technology, platform, and language independent. Largely a manual process primarily for transaction systems. Backfiring, FP derived from SLOC, is inaccurate and misleading. Results are logical. Estimates are from the user’s perspective. Accurate counting requires in- depth knowledge of standards and extensive training. Estimates from requirements through full life-cycle. Variations exist that are not standardized. Exhibit : Function Point Advantages and Disadvantages

The COCOMO model Effort = a(NCSLOC/1000) b Embedded systems: a=3.6 b=1.2 Semi-detached: a=3.0 b=1.12 Application: a=2.4 b=1.05

COCOM II Effort = A(size) b П EM(i) b = B ∑SF(j); SF(j) are 5 scale factors EM(i) : 17 cost drivers See:

Time Staff-month T theoretical 75% * T theoretical Impossible design Linear increase Boehm: “A project can not be done in less than 75% of theoretical time” T theoretical = 2.5 * 3 √staff-month